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1. Scope 

The Wireless Application Protocol (WAP) is a result of continuous work to define an industry-wide specification 
for developing applications that operate over wireless communication networks. The scope for the WAP Forum is 
to define a set of specifications to be used by service applications. The wireless market is growing very quickly, 
and reaching new customers and services. To enable operators and manufacturers to meet the challenges in 
advanced services, differentiation and fast/flexible service creation, the WAP Forum defines a set of protocols in 
transport, security, transaction, session and application layers. For additional information on the WAP 
architecture, please refer to 'Wireless Application Protocol Architecture Specification " [WAPARCH]. 

Multimedia Messaging Service (MMS) is a system application by which a WAP client is able to provide a 
messaging operation with a variety of media types. The service is described in terms of actions taken by the WAP 
MMS Client and its service partner, the MMS Proxy -Relay, a device which operates as a WAP Origin Server for 
this specialised service. Additional service aspects are supported by the MMS Server as well as other messaging 
servers, such as an email server and wireless messaging systems (e.g. SMSC). This specification defines 
application-level protocol activities that take place to realise the MMS service within the WAP environment. 
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2. Document Status 
2.1 Document History 



Date 


Description 


25 Apr 2001 


Initial version. 



2.2 Errata 

Known problems associated with this document are published at http://www.wapforum.org/ . 

2.3 Comments 

Comments regarding this document can be submitted to the WAP Forum in the manner published at 
http://www.wapforum.org/ . 
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4. Definitions and Abbreviations 

4.1 Terminology 

This document is informative and does not contain any requirements. 

4.2 Definitions 

This section introduces a terminology that will be used throughout this document. 
Email Server 

A generic class of servers that nominally hosts email services that operate using the SMTP, POP and/or 
IMAP protocols. 

Multimedia Messaging Service (MMS) 

A system application by which a WAP client is able to provide a messaging operation with a variety of 
media types. 

MMS Client 

The MMS service endpoint located on the WAP client device. 
MMS Proxy -Relay 

A server which provides access to various messaging systems. It may operate as a WAP origin server in 
which case it may be able to utilise features of the WAP system. 

MMS Server 

A server that provides storage services and operational support for the MMS service. 

4.3 Abbreviations 

For the purposes of this specification the following abbreviations apply. 



Email 


Electronic mail 


ESMTP 


Extended Simple Mail Transfer Protocol 


HTTP 


HyperText Transport Protocol, for details see [RFC2616] 


IMAP 


Internet Message Access Protocol, for details see [RFC2060] 


ISDN 


Integrated Services Digital Network 


MIME 


Multipurpose Internet Mail Extensions 


MMS 


Multimedia Messaging Service 


MSISDN 


Mobile Station ISDN Number 


PKI 


Public Key Infrastructure, for details see [PKI] 


POP 


Post Office Protocol, for details see [RFC1939] 


SMIL 


Synchronized Multimedia Integration Language 


S/MIME 


Secure/Multipurpose Internet Mail Extensions 
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Short Message Service 




oimpie Mail iransier rrotocoi, ror details see [KrLo21 J 


WAP 


Wireless Application Protocol 


WEM 


WAP Identity Module, for details see [WIM] 


WML 


Wireless Markup Language 


WSP 


Wireless Session Protocol, for details see [WSP] 


WTLS 


Wireless Transport Layer Security 
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5. Introduction 

The Multimedia Messaging Service (MMS), as its name implies, is intended to provide a rich set of content to 
subscribers in a messaging context. It supports both sending and receiving of such messages by properly enabled 
client devices. An example of such a message is shown in Figure 1 below. 




Figure 1 Example Message with Multimedia Content 



The Multimedia messaging service is viewed as a non-real-time delivery system. This is comparable to many 
messaging systems in use today. Prime examples include traditional email available on the Internet and wireless 
messaging systems such as paging or SMS, These services provide a store -and-forward usage paradigm and it is 
expected that the MMS will be able to interoperate with such systems. 

Reakime messaging also exists in various forms. For example, instant messaging available from various vendors or 
various chat services (e.g. text, voice) are becoming popular. Such services are not currently supported with the 
MMS system but may be considered for future releases. 
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6. MMS Messaging Framework 

A key feature of MMS is the ability to support messaging activities with other available messaging systems. This 
is shown in Figure 2 below which shows an abstract view of an MMS network diagram. It is expected that specific 
MMS networks may have one or more such connections as well as include specific messaging services not directly 
represented (e.g. fax or voice mail systems). 




Figure 2 MMS Network Representation 



Note that although Figure 2 identifies various interfaces, in some cases, their definition will be for further study. 
The mention of these interfaces in this document does not imply that the WAP forum will develop the 
specifications necessary to describe them in detail. 

The system elements shown in Figure 2 can be summarised as follows: 

• MMS Client - This is the system element that interacts with the user. It is expected to be implemented as an 
application on the user's wireless device. 

• MMS Proxy-Relay - This is the system element that the MMS Client interacts with. It provides access to the 
components that provide message storage services, and it is responsible for messaging activities with other 
available messaging systems. Some implementations may combine this component with the MMS Server. 
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• MMS Server - This system element provides storage services for MM messages. Some implementations may 
combine this component with the MMS Proxy -Relay. 

• Email Server - This system element provides traditional Internet email services. It supports the SMTP 
protocol to send messages as well as POP and/or IMAP protocols to retrieve messages. 

• Legacy Wireless Messaging Systems - This system element represents various systems that currently exist 
in support of wireless messaging systems. This would include paging and SMS systems that provide 
messaging to a large number of subscribers. 

The interfaces shown in the diagram are described as follows: 

• MMSm - the interface defined between the MMS Client and the MMS Proxy -Relay, see section 7, 
[MMSCTR] and [MMSENCAPS]. 

• MMSs - the interface defined between the MMS Server and the MMS Proxy -Relay. This interface may be 
transcendental when the MMS Server and MMS Proxy -Relay are combined into a single component. The need 
to define this interface has not yet been established. 

• MMSr - the interface defined between MMS Proxy -Relays of separate MMS Systems, see section 9. 
Currently, there is no specification that defines this interface. This interface may be standardised in the future 
by the WAP forum or by some other standardisation body. 

• E - the standard email interface used between the MMS Proxy -Relay and internet-based email systems utilising 
SMTP, POP and IMAP transport protocols, see section 8. This interface may be standardised in the fiiture by 
the WAP forum or by some other standardisation body. 

• L - the interfaces used between the MMS Proxy -Relay and legacy wireless messaging systems. As there are 
various such systems, this is viewed as being a set of interfaces. This interface may be standardised in the 
future by the WAP forum or by some other standardisation body. 

6.1 Example Use Case 

The following example information flow for a use case is provided to further illustrate the functions and roles of the 
various system elements in the MMS framework. The example given here concerns end-to-end MMS messaging 

between terminals. 



1 . User activates MMS Client (assumed to be available on terminal). 

2. User selects or enters MM target address(es). 

3. User composes/edits MM message to be sent. 

4. User requests that MM message is sent. 

5. MMS Client submits the message to its associated MMS Proxy -Relay via the MMSm interface. 

6. MMS Proxy -Relay resolves the MM target address(es). 

7. MMS Proxy -Relay routes forward the MM to each target MMS Proxy -Relay via the MMSr interface. 

8. The MM is stored by the MMS Server associated with the target MMS Proxy -Relay. 

9. Target MMS Proxy -Relay sends a notification to target MMS Client via the MMSm interface. 

10. Target MMS Client retrieves the MM from the MMS Server. 

1 1 . Target MMS Client notifies target user of new MM available. 

12. Target user requests rendering of received MM message. 

13. Target MMS Client renders MM message on target user*s terminal. 



Note that steps 1-3 and 12-13 concern the User Interface on the terminal which is considered implementation 
dependent and therefore outside the scope of this specification. Also note that steps 10 and 1 1 could occur in 
reverse order depending on MMS Client implementation, that is, an MM retrieval policy could cause the MMS 
Client to retrieve an MM only when so allowed by the user. 
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The above use case, as well as many others, is supported by MMS. The MMS featxires and functions described in 
the subsequent sections include: 

• The MMSm, E, and MMSr interfaces. See sections 7, 8 and 9. 

• The WAP MMS client-side structure, which is involved during MM composition, sending, receiving, 
presentation and rendering. See section 10. 

• MMS addressing aspects, which have implications for all the MMS defined interfaces and system 
elements in the MMS framework. See section 11. 

• MM presentation, which may be used when rendering an MM on an MMS Client. See section 12. 

• Security services that may be available to the MMS application on a per-link or end-to-end basis. See 
section 13. 

• Content adaptation services that an MMS system may be able to provide before delivering an MM. See 
section 14. 
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7. MMS Client / MMS Proxy-Relay Interface 

As shown in Figure 2, the MMS Client interacts with the MMS Proxy -Relay. This operation is consistent with the 
WAP model where the MMS Proxy -Relay operates as an Origin Server (Pull Operations) or as a Push Initiator (Push 
Operations). 

The relationship between the MMS Client and MMS Proxy -Relay is shown in Figure 3 below. The messages that 
transit between the two components are normally transferred using a wireless transport such as WSP between the 
WSP Client and the WAP Gateway, and then transit over HTTP from the WAP Gateway to the MMS Proxy -Relay. 




MMS 
CUent 



WAP 
Gateway 














HTTP 



MMS 
Proxv-Relav 

> 



Figure 3 Logical Architecture of MMS Client to MMS Proxy-Relay Link 



This network representation includes a few items that need to be described. The MMS Proxy -Relay is the network 
entity that interacts with the user mailbox and is responsible for initiating the notification process to the MMS 
Client. The WAP Gateway provides standard WAP services needed to implement MMS, these include: HTTP 
methods; PUSH services; OTA security; and Capability Negotiations (UAProf). 

The MMS system is guided by activities between the MMS Client and MMS Proxy -Relay. These activities are 
described in the WAP MMS Client Transaction document [MMSTC] and the MMS Encapsulation document 
[MMSENCAPS]. 

The network view also shows a payload that is carried by the wireless transport and HTTP. This payload is 
described in the WAP MMS Message Encapsulation document [MMSENCAPS]. It is expected that this data will 
be transported in its entirety between the MMS Proxy -Relay and the User's Terminal. 
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8. MMS Internet Email Interworking 

One of the important links on the Network Diagram is the connection of the MMS Proxy -Relay to Email Servers 
connected via the Internet. This connectivity works in both directions. 

8.1 Sending Messages To Internet Email Servers 

For sent messages, the MMS Proxy -Relay will submit the message to the addressed host using the SMTP protocol. 
The message payload will be converted to standard Internet MIME format to permit the various media components 
to be carried consistently into the Internet environment. The MMS specific header fields will be converted into 
appropriate headers by prepending an *X-Mms-' to the header name. This will permit MMS aware systems to 
imderstand the fields while not being problematic for non-MMS aware systems, 

8.2 Receiving Messages Sent From Internet Email Systems 

Received messages will be similarly converted. The MIME part of the message will be converted to the MMS 
format. Similarly, any headers found with a prefix of 'X-Mms-' can be converted back to the associated MMS 
header. 

8.3 Retrieving Messages From Internet Email Servers 

It will be important for MMS Clients to be able to retrieve messages that are stored on Internet Email servers. This 
is normally done through the use of the POP or IMAP protocols. Such retrievals are performed by the MMS Proxy - 
Relay (this is one of the proxy roles), which will then convert the data into an appropriate MMS format. 
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9. MMS Proxy-Relay to Proxy-Relay Operation 

MMS systems provide services and capabilities that are different than other messaging systems. When such 
systems communicate with each other, some of these services and capabilities are to be provided between them. 
Over time, it is expected that these specialised services and capabilities will be further enhanced. Therefore, it is 
important that these systems can inform and support the services between MMS systems. 

If the MMS Proxy -Relay to Proxy -Relay operation is based on Internet email approaches, then SMTP/ESMTP may 
be used for the interconnect. Alternatively, the interconnect may employ some other suitable commimication 
protocol 

9.1 Discovery of Peer MMS Proxy-Relay Elements 

Before any efficient activities can be performed between cooperating MMS Proxy -Relays, an MMS Proxy -Relay will 
need to know that it is communicating with another MMS Proxy -Relay. Depending on the protocols used between 
these elements, different methods may be utilis ed. For example, when using normal SMTP email, the capability 
reporting schemes of the ESMTP [RFC 1869]* and [RFC 1 870]* negotiation scheme would be the expected method. 

* Note that ESMTP is specified across a large number of RFCs and those listed above, together with SMTP, simply 
define a framework that may be extended. Other specific aspects of ESTMP can be found by reading the relevant 
RFC related to the feature of interest. 

With the awareness that an MMS Proxy -Relay is communicating with a peer component, they may be able to 
perform additional operations that could improve the efficiency or extend the conmiunication capabilities between 
them. The effective or negotiated capabilities that could be supported between peer systems will be conunimicated 
as part of the discovery process. 

9.2 Message Flows Between Cooperating MMS Proxy-Relays 

The MMS Proxy -Relays will be responsible for extending the current data flows that have been documented for 
MMS Client to MMS Proxy -Relay (home system) to reach the MMS Proxy -Relay (target system) at another MMS 
system. These extended message flows could operate over SMTP or other communication protocol The 
commimication between these elements will utilise the message headers available from the MMS Clients as well as 
new ones specifically for the peer MMS Proxy -Relay link. 
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10. MMS Client-Side Structure 

The general model of how the MMS user agent fits within the general WAP Client architecture is depicted in Figure 
4, 



Application Framework 
(WAE, Push Dispatcher, MMS User Agent) 



Content 

Network Renderers Common Functions WIM EF! 

Protocols (Images, (Persistence, Sync, 

Multimedia, etc. etc.) 



Figure 4 General WAP Client Architecture 



The MMS User Agent is responsible for the composition and rendering of multimedia messages. Message 
rendering is performed by utilising the appropriate content rendering service. The MMS User Agent is also 
responsible for sending and receiving multimedia messages by utilising the message transfer services of the 
appropriate network protocols. 

The MMS User Agent, as described in the WAP MMS specifications, is not dependent on, but may use, the 
services of the other components shown in Figure 4, i.e. the Common Functions, WIM and EFI. 

Additional information about the general WAP Client architecture is available in the current [WAPWAE] 
docimient. 
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11. MMS Addressing 

An important aspect of messaging systems is the ability to address the users in a way that can be efficient for the 
system as well as meaningful for the senders of messages. This balance is difficult to achieve. 

11.1 Internet Addressing 

In the Internet world, where bandwidth is not a primary consideration, addresses are normally expressed in the 
email address paradigm. In this scheme, addresses look like user@system where the system specification may be a 
domain name or a fully qualified host address. In general, this scheme provides users the ability to have a complete 
and unique address in an unboimded text string. This scheme is very conmion and such addresses are routinely 
printed on business cards. 



1 1 .2 Wireless network addressing 

In the wireless world, where bandwidth efficiency is critical, short address lengths and ease of user entry on limited 
keypads are the hallmarks of the various systems. For example, in GSM networks, a user's address is based upon 
the MSISDN number utilised by the device. Similarly, in many paging systems, users are assigned PINs that would 
permit a caller to deposit a message. 

The MMS addressing model, as defined in [MMSENCAPS], makes such a more direct or efficient addressing 
scheme available to MMS subscribers and services. This is seen as particularly important for interoperability with 
legacy systems such as the above mentioned, and e.g. for mobile -to-mobile operation. 

As message traffic has increased to wireless systems from the wireline world, most such systems have deployed 
servers that provide external entities the opportunity to address their email to the wireless subscribers directly. 
Many such systems utilise an ID^carrier approach to setting these addresses for access firom email systems. 

MMS employs an extensible addressing scheme that permits a variety of addressing paradigms to be supported. 
More specific details on addressing can be found in the MMS encapsulation specification [MMSENCAPS], 
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12. MMS Presentation 



12.1 Multimedia presentation concepts 

The concept of MMS presentation means the ordering, layout, sequencing and timing of multimedia objects on the 
terminal screen and other devices such as a speaker. With MMS presentation, the sender of the multimedia 
message has the possibility to organise the multimedia content to a meaningful order and to instruct how the 
multimedia objects are rendered at the receiving terminal. 

Today, terminals generally have small screens and limited audio capabilities. In the future, however, it can be 
expected that the capabilities of terminals will improve making full multimedia presentations possible. The use 
cases for MMS presentation include advertisements, news flashes etc. To allow content providers to create 
multimedia presentations compatible with as many terminals as possible, it is important that MMS presentations are 
handled consistently, and consideration is given to the current and future capabilities of terminals and their 
interoperability. 

MM presentation is optional, as some terminals have very limited presentation capabilities. However, receiving 
terminals may still be able to render the received multimedia content as long as they support the media types in the 
message, even if the presentation instructions, such as sequencing, layout and timing information, are not 
supported. 

12.2 Presentation examples 

There are various alternatives for presentation language, most notably [WML] and Synchronised Multimedia 
Integration Language SMIL™ [SMIL]. 

12.2.1 WML 

The WML presentation for multimedia messaging offers the same sequencing and layout capabilities as with 
browsing. 

12.2.2 SMIL 

The SMIL™ provides extended capabilities, such as timing of multimedia objects as well as animation. 

The SMIL™ is a simple XML-based language that consists of a set of modules that define the semantics and 
syntax for certain areas of functionality. Examples of these modules are layout module, timing and synchronisation 
module and animation module. A SMllT^ profile is a collection of modules particular to an application domain. The 
SMIL™ basic profile is a lightweight profile providing limited number of modules and thus is particularly relevant to 
multimedia messaging. 

The MMS presentation language is transferred in the same message that the multimedia objects are transferred. 
Thus, a multimedia message is a compact package of multimedia objects and optional presentation information. The 
presentation language contains pointers (e.g., URLs) to the multimedia objects in the message. 
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13. Security Considerations 

The MMS service is primarily an application level service. As such, it is able to build upon various security 
services available to applications. For example, the conmiunication between the MMS Client and a WAP Gateway 
may be encrypted by use of the services available from the WTLS service layer. Other security service may be 
accomplished by use of other defined security services that are available to the appropriate components. 

Example security services include: 

WTLS The WAP WTLS layer provides for a secure data transmission between the WAP Client 

and the WAP Gateway. 

WDM The WAP Identity Module [WIM] is used in performing WTLS and application level 

security functions, and especially, to store and process information needed for user 
identification and authentication. 

PKI Public Key Infrastructure [PKI] refers to the infrastructure and procedures required to 

enable the trust relationships needed for the authentication of servers and clients. 

S/MBME Secure MIME [RFC2633] provides a means of handling the encryption of MIME 

components. This is useful for messages that are conveyed over SMTP. S/MIME 
provides a set of security services that includes authentication, message integrity, non- 
repudiation of origin (usmg digital signatures), privacy and data security (using 
encryption). 

The MMS does not provide its own specific security support and does not mandate any specific security solution. 
Though it may be possible to encrypt the contents of a message, it raises the possibility that complete end-to-end 
security for MMS messages and control activities may be unattainable. An aspect of the MMS user interface is 
that of conveying information related to the security and/or authentication of messages received or to be sent. As 
with some Internet browsers, iconic representations are available to provide basic information to users regarding 
the security of the viewed message. Additional details regarding the message can normally be viewed as well. 
Such schemes would be desirable for MMS Clients but are not being mandated at this time. 
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14. Content Adaptation 

One of the possible services that an MMS system may be able to provide is content adaptation. In effect, there 
may be the opportunity to convert, replace or delete certain data elements from a multimedia message before 
delivering it to the MMS Client. 



14.1 Determining Need for Content Adaptation 

Such service may be prompted for a variety of reasons: 

• Device Capability - Devices may have limitations that may prevent them from being able to handle a particular 
type. These limitations may be based upon content type, characteristics or size (e.g. buffer space). 

• Bandwidth Considerations - Certain data types may be inappropriate for a particular type of bearer (e.g. 
streaming over SMS). Such considerations may be based upon factors set by a user or a network operator. 

• Roaming Considerations - There may be issues having various multimedia data conveyed over an alternate 
carrier's network. There may be service constraints or pricing considerations that may impact the delivery of 
message elements. Such filtering should occur at the 'home' system. 

There are various services that may assist the MMS system to determine whether content adaptation is needed. In 
particular, the WAP UAProf [UAPROF] provides a mechanism to inform the MMS Proxy -Relay witfi information 
about the MMS Client. This information relates to characteristics of the device and serving network. 



14.2 Content Adaptation Activities 

Various fomis of content adaptation may be performed. For example, graphic images may be removed, scaled or 
colour converted. 

Specific content adaptation services are beyond the scope of the MMS specifications. 
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15. WAP MMS Documents 

• MMS Architecture Overview 

This document. This is to be a starting point for anybody wanting to know more about MMS. 

• MMS Client Transactions 

The document [MMSCTR] describes the operation of the MMS messaging system as it operates between 
the MMS Client and the MMS Proxy -Relay. 

• MMS Encapsulation Protocol 

The document [MMSENCAPS] describes the protocol operating between the MMS Client and the MMS 
Proxy-Relay. 
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